The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
DNS-based blacklists and whitelists for e-mail are described in J. Levine, “DNS Based Blacklists and Whitelists for E-Mail,” draft-irtf-asrg-dnsbl-01.txt, Nov. 16, 2004. The term “DNSxL” is used as shorthand to refer to either a DNS-based blacklist (DNSBL) or a DNS-based whitelist (DNSWL).
IronPort Systems, Inc. has introduced a service termed “SenderBase Reputation Score” or SBRS. Using SBRS, a mail transfer agent configured with appropriate software can issue a query to a database that stores information about the reputation of senders of electronic messages. The database replies with a value indicating a sender's reputation. Based on the value, the mail transfer agent can determine whether to accept or reject the message.
In one implementation of SBRS, a sender reputation list is implemented in the form of a DNSxL. The DNSxL sender reputation list enables the use of less fine-grained sender reputation score data by devices and services that are unable to process the actual scores directly. In one approach, real-valued sender reputation list scores are separated or “discretized” into a finite set of “bins.” These bins are associated with standard DNS responses, indicating various ranges of reputation scores. Further, the DNSxL format is supported by many clients, and allows a wider range of devices and services to use sender reputation list.
However, because many clients support DNSxL format, a reputation service could be subject to a denial-of-service attack by clients that send large numbers of successive queries that request reputation values for non-existent senders or network addresses. To prevent such attacks, there is a need to identify valid and invalid clients and to control their access to the service. There is a related need to perform validation and control in a way that is computationally “light” for both clients and the reputation service, and allows for time-limited access as well as distinct service groups.
Message authentication code (MAC) approaches are known for enabling a receiving network node to determine if a message has been modified in transit from a sender. Some MAC approaches are based on performing a one-way hash over the message using a collision-resistant, fixed-length-output hash algorithm such as Message Digest 5 (MD5).